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ABSTRACT 


This paper investigates the emerging tenn “mission engineering” through the 
framework of systems engineering and systems integration. Systems engineering 
concepts, processes, and methodologies are extrapolated for use in conjunction with a 
systems integration, life-cycle based framework to effect mission engineering. The 
specific systems engineering concepts of measures of effectiveness, performance and 
suitability are recommended as foundational to establishing mission-engineering 
processes to satisfy mission user requirements, and ultimately provide a context for 
definition of mission engineering. 
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EXECUTIVE SUMMARY 


The term “mission engineering” has been used recently in academic and 
Department of Defense (DOD) circles without formal definition or scope. However, the 
use of the term in systems engineering contexts implies a relationship that can be 
explored in an attempt to define mission engineering. 

The purpose of this paper is to explore key aspects of the systems engineering 
discipline for applicability and utility in defining the new concept of mission engineering. 
This is accomplished by examining the definition and critical processes of systems 
engineering, and then applying those key systems engineering attributes to defining 
mission engineering and proposing mission engineering processes. 

Systems engineering is a well-defined field of study with a multitude of fonnal 
definitions. Systems engineering can be defined as an interdisciplinary approach and 
means to enable the realization of successful systems (INCOSE 2015) or “a methodical 
and disciplined approach for the specification, design, development, realization, technical 
management, operations, and retirement of a system” (Department of Defense 2013, 
158). Irrespective of definition, systems engineering encompasses several key processes 
that will be useful in providing context to mission engineering. Those key processes are 
identification of user needs, decomposition of needs into executable requirements, and 
verification and validation that system requirements and user needs are met by the 
resulting systems engineering solution. Additionally, in order to effect successful 
execution of these foundational systems engineering processes, specific metrics need to 
be defined and data collected. Several metrics used in systems engineering are measures 
of performance, measures of suitability, and measures of effectiveness. Measures of 
performance assist the systems engineer with verifying requirements are satisfied, 
measures of suitability provide evidence that validates the system for a specific user- 
defined environment, and measures of effectiveness demonstrate the system is useful to 
meet operational needs. 



A simple definition for mission engineering is postulated, derived from the 
definitions of the tenns “mission” and “engineering,” as the application of science and 
mathematics in the execution of a specific task with which a person or a group is charged. 
However, the purpose of this paper is to use systems engineering concepts as a 
framework to define mission engineering. First, similar to systems engineering, user 
needs and the derivation of mission requirements must be an iterative process to clearly 
articulate executable requirements to the mission developers, so planners can determine 
the best solution within perfonnance, cost, schedule, and other constraints. Second, 
systems engineering processes of verification and validation are needed in a mission 
engineering process to ensure mission solutions meet user needs and derived 
requirements. Measures of performance and suitability provide the necessary data to 
verify and validate that the mission requirements are satisfied and to what degree. This 
allows for mission engineering, including iterative trade-space decision making similar to 
iterative systems design and development cycles. Finally, measures of effectiveness are 
recommended for use in the final stages of mission engineering during mission execution 
to provide the end user and other mission stakeholders with quantifiable data that shows 
the level of mission success, allowing the mission engineer to refine mission 
requirements or mission parameters as needed. 

Mission engineering is expected to be complex and in need of clear definitions, 
processes, and methodologies. This thesis recommends the use of specific systems 
engineering processes supported by measures of effectiveness, perfonnance, and 
suitability as foundational elements from which to build mission engineering processes. 
In addition, a more detailed definition of mission engineering is proposed, extrapolated 
from definitions of systems engineering and systems integration (INCOSE 2004; 
Department of Defense 2013; Langford 2012) is as follows: 

Mission Engineering is a life cycle based, integrative approach to develop 
and implement capabilities and functions from stakeholder needs into 
executable missions while balancing performance, risk, cost and schedule. 

This thesis concludes that execution of mission engineering requires a life-cycle 
perspective using systems integration methods and systems engineering tools and 


xiv 



processes. Systems engineering and integration have well-developed tenninology and 
clear, executable processes that are applicable and are recommended to be used in the 
execution of mission engineering. Specifically from systems engineering, stakeholder and 
requirement analysis, verification and validation processes, and associated measures of 
effectiveness, performance, and suitability are foundational elements that can be tailored 
for unique missions and mission-focused processes to ensure mission requirements are 
clearly defined, allocated, and ultimately met by the mission solution. Additionally, 
systems integration is a framework for understanding mission engineering as mission 
engineering involves the integration of systems or systems of systems to execute 
stakeholder defined capabilities and functions. Systems integration provides a means to 
develop capabilities, functions, and solutions to problems beyond those of individual 
systems. The major processes within mission engineering are the mission requirements 
derived from stakeholder needs, mission conceptualization, mission design, and mission 
architecting. Within each of these iterative phases, and throughout the mission 
engineering process, life-cycle considerations must be accounted for and reacted to, as 
needed. Iterations of design architecture are based upon measures of effectiveness, 
performance, and suitability depending on the specificity of the capability or function in 
question and the stage in the mission engineering process. Perfonnance measures may be 
used early and often to verify specific aspects of the mission design, whereas measures of 
suitability and effectiveness are more often used later in the mission engineering process 
when closer to a final solution. Mission engineering is a life-cycle based, integrative 
approach to develop and implement capabilities and functions from stakeholder needs 
into executable missions while balancing perfonnance, risk, cost and schedule. 

A recommendation for future study is to further explore the emerging field of 
mission engineering. While this thesis proposes a construct of mission engineering 
utilizing the framework of systems integration and the tools and processes of systems 
engineering, additional specificity for mission engineering unique processes may be 
beneficial. Additional detail in mission engineering processes and terminologies may 
allow for greater application of mission engineering and may result in an entirely separate 
field of study from systems engineering. 
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I. BACKGROUND 


A. SYSTEMS ENGINEERING 

Unlike traditional engineering disciplines (e.g., mechanical engineering or 
electrical engineering), systems engineering does not have a single, clear definition that is 
used throughout the academic and public arenas. However, all of the definitions highlight 
specific aspects of systems engineering and expose the user to the importance of those 
aspects of systems engineering over other aspects. The following definitions are provided 
as context to demonstrate how systems engineering can be defined in a broad context 
with a multitude of processes but also defined more narrowly based upon the interests or 
preferences of the organization generating that definition: 

The International Council on Systems Engineering (INCOSE) defines systems 
engineering as “an interdisciplinary approach and means to enable the realization of 
successful systems” (INCOSE 2004, 12): 

Systems Engineering is an overarching discipline, providing tradeoff 
analyses and integration between system elements to achieve the best 
overall product and/or service. Although there are some important aspects 
of project management... it is still much more of an engineering focus 
than a management discipline. (INCOSE 2004, 10). 

These definitions focus on the development of a specific product and the use of 
specific systems engineering processes to support that development. Furthermore, the 
INCOSE definitions highlight the blending of an engineering discipline and management. 
The organization and management of the processes employed by the systems engineer is 
just as important as the execution of the processes themselves, especially when planning 
and managing a system through its life cycle. 

The Institute of Electrical and Electronics Engineers (IEEE) describes the goal of 
systems engineering as 

developing, producing, testing, and supporting an integrated set of 
products (hardware, software, people, data, facilities and material) and 
processes (services and techniques) that is acceptable to stakeholders, 
satisfies enterprise and external constraints and considers and defines the 
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processes for developing, producing, testing, handling, operating, and 
supporting the products and life cycle processes. (Institute of Electrical 
and Electronics Engineers 2005, iv) 

While this definition parallels the INCOSE definition to develop a system, it is 
important to note the focus on a complete life cycle balanced solution and the satisfaction 
of internal and external demands. Looking at systems engineering through this lens, a 
systems engineer will emphasize the involvement and satisfaction of the customer but 
also assign high importance to the satisfaction of other internal and external demands. 

The Defense Acquisition Guidebook (DAG) defines systems engineering as “a 
methodical and disciplined approach for the specification, design, development, 
realization, technical management, operations, and retirement of a system” (2013, 158). 
The DAG definition of systems engineering is a narrowly focused definition of systems 
engineering. The systems engineering process is presented as a linear systematic process 
to define, realize, manage, and ultimately dispose of a system. However, within each 
phase of the systems engineering process, an iterative process is used to determine the 
outcome. Additionally, the DAG definition specifies a methodical and disciplined 
approach, whereas previous definitions simply stated an approach was used. Enhanced 
discipline and adherence to rigorous methods in the DAG definition is due to the high 
focus on compliance, traceability, and oversight in the government arena. 

The varying definitions of systems engineering highlight the universality of systems 
engineering concepts and the flexibility with which those concepts can be applied. Some 
organizations use a broader definition of systems engineering while others focus on specific 
aspects of systems engineering that are more important to service their needs. 

B. MISSION ENGINEERING 

Mission engineering is a hitherto undefined term that affords great latitude when 
proposing a definition. A good starting point is the definition of the individual 
constitutive words. Merriam-Webster provides the following definitions for “mission” 
applicable in a military context: “a specific task with which a person or a group is 
charged” and “a definite military, naval, or aerospace task.” It also provides the following 
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definitions of engineering as “the application of science and mathematics by which the 
properties of matter and the sources of energy in nature are made useful to people” and 
“the design and manufacture of complex products.” At an elemental level, one can define 
mission engineering as the application of science and mathematics in the execution of a 
specific task with which a person or a group is charged. However, this definition is 
general and does not provide a user with an understanding of how mission engineering is 
performed or what processes to use in the execution of mission engineering. This is 
where the context of a well-defined discipline, such as systems engineering, provides the 
framework and limits to better define mission engineering. 

Due to the broad applicability of systems engineering concepts and methods, the 
term “mission engineering” may be defined in terms well established in the systems 
engineering field of study. This thesis explores answers to the questions, “What is 
mission engineering?” and “How can systems engineering processes be used to lay a 
foundation for consistent application of mission engineering?” This thesis answers these 
questions by establishing a framework to define mission engineering through the use of 
accepted definitions, processes, and methodologies already existing in the field of 
systems engineering. Through the systems engineering lens, mission engineering as a 
systems process is explored and in that manner provides a foundation for developing a 
formal definition. 
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II. SYSTEMS ENGINEERING 


A. SYSTEMS ENGINEERING AS A FRAMEWORK 

Systems engineering is a well-documented engineering discipline with codified 
processes, methodologies, and definitions used to design and develop systems to suit user 
needs. The formalized definitions and processes of systems engineering are a logical 
framework to explore, understand, and define the new term mission engineering. 

As the name implies, systems engineering is the use of specific processes to 
design and develop systems. However, systems engineering is unique from other 
engineering disciplines. Langford (2012, 218-219) describes the uniqueness of systems 
engineering through its focus on “(1) the product or service as an enabler of the desired 
user behaviors, (2) satisfying the stakeholders’ needs can be done in one of many ways, 
(3) and the desired consequences of the product or service for people, infrastructure, and 
environment need to be incorporated by design and architecture.” Systems engineering 
methods and processes are used to derive a multitude of potential solutions from user 
needs and requirements, focus solutions on satisfying the users’ needs, and consider 
internal and external influences on the system both near term and long tenn. In this 
regard, systems engineering is a life-cycle approach to designing and building products 
and services. 

Systems engineering covers a broad range of activities in a product life cycle from 
deriving requirements from stakeholder needs, implementing requirements into design of 
systems and subsystems, and verifying and validating that the resultant product or service 
has met the original stakeholder needs and requirements. This high-level system 
engineering process is iterated continuously at varying levels of specificity throughout 
the life cycle of the system. Figure 1 illustrates this high-level system engineering 
approach to satisfying stakeholder needs. This thesis focuses on a portion of the systems 
engineering cycle - the derivation of stakeholder needs and requirements and the 
verification and validation that the product meets those needs and requirements. These 
areas of the system engineering cycle are used to provide context and basic definition to 
the term “mission engineering.” 
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Figure 1. Systems Engineering Model (from Department of Defense 2012[d]) 


B. NEEDS AND REQUIREMENTS 

The starting point, and one of the most important elements in the systems 
engineering process, is the development of stakeholder needs and derivation of system 
and subsystem requirements. The requirements development stage is paramount to 
successful system engineering and development because all subsequent processes and 
steps in the design cycle require clear definition of requirements that are attainable and 
suitable to satisfy the stakeholder needs. 

The development of a new system begins by clearly identifying a problem in 
order to identify the need for a new system to delineate solutions that respond to that 
problem. It is paramount to have a clearly identified need prior to requirement generation, 
in order to avoid the system engineering process being driven by personal or political 
interests. The satisfaction of stakeholder needs and the subsequent requirements that are 
derived from those stakeholder needs are the driving force behind the systems 
engineering process. Therefore, the verification and validation of those needs and 
requirements is equally important to successful execution of systems engineering. 
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1. Needs and Requirements Generation Processes 

One of the technical processes to ensure successful systems engineering is the 
requirements generation process. During the requirements development phase (may also 
be referred to as the requirements analysis phase), user needs are translated into 
functional and performance requirements. The resulting set of system requirements will 
define functionally what the system is required to do and define the perfonnance required 
for each function (Defense Acquisition University 2015). An iterative process of 
functional analysis and allocation of requirements is used to ensure the final requirements 
are understandable, unambiguous, executable, concise, and completely define the needs. 

Bijan et al. (2011) review and discuss several methods for requirements 
generation, prioritization, and analysis however, conclude that more work may be needed 
to codify an end-to-end process for translating user needs into precise, unambiguous 
requirements for successful systems engineering of complex systems. One process 
described for initial identification and organization of requirements is Quality Function 
Deployment; in this process stakeholder needs are defined and grouped diagrammatically 
to aid the systems engineer in understanding the relationships between various needs and 
to identify similarities, differences, or redundancies. Another method for generating 
requirements is the use of a use case, or a scenario in which the requirement may be 
satisfied. The use case process is aimed at identifying unnecessary requirements or 
identifying functional or performance gaps in the requirements set that may lead to 
articulating additional requirements, or requesting clarification from stakeholders. 
Ultimately the requirements generation process may be uniquely based upon the size, 
complexity, or other features of the specific system, but some common features of 
successful requirements development processes are: keep users involved; iterate and 
refine requirements; organize, monitor, and track requirements; and clearly document all 
requirements and how and why they change (Turk 2005). 

2. Needs and Requirements Management 

The monitoring and tracking of requirements through the system life cycle 
necessitates a method for requirements management. Requirements management is 
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important to a successful system engineering approach because requirements may evolve 
and the system engineer will need to respond to those changes. Some reasons for 
requirements evolution are changing stakeholder needs, changing technologies, budgetary 
constraints, modifications within an organization, or working with new vendors, which 
may impose additional constraints on the system (Turk 2005). Chapter 4.3.5 of the DAG 
describes the requirements management process as a method of requirements traceability 
from stakeholder need, or high-level system requirement, through system level elements 
in a functional breakdown of the system to the lowest level of design (Department of 
Defense 2013). This level of traceability enables the systems engineer to manage 
efficiently requirements modifications and their impact on a developing or developed 
system. 


C. REQUIREMENTS VERIFICATION AND VALIDATION 

While the derivation of requirements from stakeholder needs is one of the initial 
steps to the systems engineering process, verifying and validating that stakeholder needs 
have been met is one of the final stages of the systems engineering process. The 
derivation of and the verification and satisfaction of stakeholder needs in the fonn of 
system requirements are two of the most important elements of the systems engineering 
process. Furthermore, the metrics and methods used to measure successful validation and 
verification are necessary for the systems engineer and the stakeholders to accept the 
final solution as an effective solution to the initial problem. The measure used to validate 
the solution is effective and to verify the solution is suitable for the user are critical 
metrics for demonstrating successful systems engineering and a successful solution. 

1. Verification 

Verification is an assessment of a system’s limitations in an effort to detennine 
whether the requirements have been satisfactorily met. This assessment is perfonned 
throughout the system engineering and development process in order to identify and 
correct issues early in design. The DAG (2013, Chapter 4.3.15) defines verification as the 
process that “provides evidence that the system or system element perfonns its intended 
functions and meets all perfonnance requirements listed in the system performance 
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specification and functional and allocated baselines.” The DAU defines verification as 
the process of confirming that each element of the system “meets the design-to or build- 
to specifications.” Verification is a critical feedback mechanism throughout the systems 
engineering process to ensure the systems and subsystems being designed, built, and 
integrated meet the requirements defined at the outset of the systems engineering process. 
To maximize benefit, verification is not only perfonned at the end of the design and 
integration cycle, but throughout the design, development, and integration phases of a 
system in order to correct any deficiencies and to provide evidence that the system is 
adequate to meet the defined requirements. 

The process for executing verification is reliant on the requirement or feature of 
the system being verified. Chapter 4 of the DAG describe four verification methods: 
examination, demonstration, analysis, or test. Examination is a visual inspection to 
detennine if the system or sub-system is in compliance with requirements. Demonstration 
is similar to examination in that visual observations are used to verify requirements; 
however, demonstration involves inspection while functions of the system are operated. 
Analysis verifies the system or sub-system through the use of analytical techniques, such 
as computer models or hand calculations, to explain performance. Finally, testing is an 
activity to demonstrate performance of a system element or function in a controllable 
scenario (Department of Defense 2013). Some or all of these processes may be used to 
verify the system throughout the life cycle, from initial concept through final design. As 
an example, analysis may be a preferred verification method early in design due to cost 
and faster iteration as needed to correct performance issues, whereas demonstration and 
testing may be used later in design when physical mock-ups or prototypes are generated 
to verify acceptable perfonnance. 

2. Validation 

Validation is similar to verification in that it is a check of the design process to 
ensure the solution and end result of the systems engineering process meets the user’s 
needs. The validation process confirms that the realized system complies with 
stakeholder needs (INCOSE 2004). While verification focuses on the system, subsystem, 
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or constitutive elements meeting specific and defined requirements in the form of 
specifications, validation tests the resulting system to acquire confidence that the system 
produces the desired result for the user. In effect, validation of the system is an 
endorsement that the process of translating user needs into requirements was successfully 
executed. As such, validation is paramount to the systems engineering process producing 
a product or service that is useful and effective for the user. 

Processes used for validation are similar to those used for verification with the 
major difference being that validation activities are centered on performance of the 
resulting system in an intended operational environment. Early in the systems 
engineering life cycle, modeling and simulation may be used to estimate the performance 
of the system in an operational setting. However, final validation of the system involves 
testing of an operational, production-representative system in the intended operational, or 
suitably simulated, environment. Additionally, end-user and other external stakeholder 
involvement in validation activities can ensure independent confirmation that the correct 
system has been developed and functions as needed (Department of Defense 2013). 

D. SYSTEMS ENGINEERING MEASURES 

1. What Is a Measure? 

Defining a measure provides a foundation for discussion of specific measures 
used in systems engineering. A measure is a quantitative or qualitative value that has 
specific meaning within a context (Langford 2012). For example, the five is simply a 
number, but may be used as a measure when a context is established such as time, 
specifically seconds; five seconds is a measure of time. Measures as used in this thesis 
are properties or attributes that are either qualitatively or quantitatively detenninable 
(Langford 2012). 

2. Measures of Effectiveness 

Verification and validation are evidence-based processes and rely on metrics and 
data to support justification that a system meets functional and performance requirements 
as well as the ultimate needs of the user. In order for the systems engineering to 
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successfully employ verification and validation, metrics must be well defined and 
articulated to ensure the effectiveness of the resultant product or service of the systems 
engineering process. One metric used to quantify the perfonnance of a system, product, 
or process with respect to what degree the real objective is achieved is a measure of 
effectiveness (INCOSE 2004). According to the DAU, measures of effectiveness are “the 
data used to measure the military effect (mission accomplishment) that comes from the 
use of the system in its expected environment” (2012 (a)). According to Langford (2014, 
7), “measures of effectiveness are intended to demonstrate to what extent objectives are 
accomplished and how well the results compare with the desired results.” The goal of 
systems engineering is to produce a product or service that is useful and valuable to the 
end user. Measuring the effectiveness of the resulting system is critical to defining the 
systems engineering processes and methodologies as successful. If the system is not 
deemed useful or valuable to the end user based upon the measure of effectiveness, the 
systems engineering processes used must be scrutinized and adjusted, as needed, to affect 
a solution that is more useful to the user. This iterative approach can be used to re-scope 
and redefine the systems engineering processes used to define the solution. Therefore, 
measures of effectiveness are important to understanding the systems engineering process 
and may be leveraged to understand and help define mission-engineering processes. Who 
and how does one determine measures of effectiveness? Sproles (2000) suggests that 
measures of effectiveness are detennined by the stakeholders because the stakeholders 
will determine if the resulting system satisfies their needs. Expanding on that observation, 
the method to determine measures of effectiveness is to identify specific properties of the 
system that are needed to satisfy the end-user or stakeholder. Sproles (2000, 55) suggests 
the question be asked: “If a candidate solution cannot do this, would I reject it?” Once 
the critical properties of the system are established, a measure must be assigned to those 
properties to afford the system engineer a qualitative or quantitative means by which to 
assess various system solutions. It is necessary to be able to test a system with respect to 
a specific measure of effectiveness; otherwise, the measure adds little value to the system 
engineer or stakeholder. Since measures of effectiveness are used to demonstrate to the 
stakeholder acceptability of the system, the viewpoint or perspective of the stakeholder(s) 
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is important to consider. The steps to detennining measures of effectiveness are to 
detennine the viewpoint from which the measure will be used, establish the functionality 
or performance desired by the system, draft a notional measure of effectiveness, analyze 
the measure of effectiveness for utility and application for the system in question, and to 
iterate and revise the measure of effectiveness as needed (Sproles 2002). 

Langford (2014, 10—12) describes a nine step process for reliably choosing 
measures of effectiveness. The process includes defining terminology, delineating 
boundaries and functions through functional analysis, performing a life cycle analysis, 
defining requirements from stakeholder needs, hypothesizing a solution, determining 
theoretical foundations, formalizing a framework, determining any losses, and analyzing 
the resulting effectiveness. 

Regardless of the method used to generate the measures of effectiveness, they are 
necessary to validate the final system solution in the intended application and are 
therefore a critical part of the systems engineering and systems integration processes. In 
addition to measures of effectiveness, measures of perfonnance and measures of 
suitability are used in the systems engineering life cycle to verify and validate that sub¬ 
system and system requirements are satisfied. 

3. Measures of Performance 

Measures of performance are a subset of measures of effectiveness that are used 
to specifically gauge the abilities of a system. Sproles (2000) highlights the distinction 
between measures of effectiveness and measures of perfonnance as the fonner describes 
the effectiveness of any solution with respect to the user needs, whereas the latter 
describes the perfonnance of a specific solution, system, or sub-system. DAU defines 
measures of performance as “system-particular perfonnance parameters such as speed, 
payload, range, time-on-station, frequency, or other distinctly quantifiable features” 
(2012 (b)). Measures of performance are used to quantify the ability of the system to 
achieve specific, individual attributes and are consequently tied to verification of the 
system. The system, and its subsystems, is verified throughout the systems engineering 
process to ensure the requirements and necessary abilities of the system are achieved, or 

to gauge the extent to which the system is unable to meet the requirements. Selecting the 
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most appropriate measures of performance is paramount to successful and meaningful 
verification of the system and ensuring the system solution meets stakeholder 
requirements. The selection of measures of performance may also guide the final solution 
as the system is iterated and verified throughout the design process. 

Measures of performance are selected and iterated through requirement allocation 
to features of the system. Performance of specific functions or features of the system are 
only necessary to be measured when they relate directly to a requirement to be satisfied. 
Therefore, establishing the measures of performance for a system, sub-system, function, 
or feature of the system involves tracing of requirements through the functional 
breakdown of the system in order to specify a measure. Iteration may be needed to revise 
the measure or measures of perfonnance used to quantify a specific function or feature of 
a system. For example, a manufacturing process employing a perfonnance measure tied 
to units produced may add specificity and define performance by units produced over a 
specified time period. Ultimately, the measure of performance is used to influence the 
systems engineering process and, as such, the measure must be linked through a system 
function or element to a specific requirement. 

4. Measures of Suitability 

Measures of suitability are also a subset of measures of effectiveness. Measures of 
suitability are used to define how well a system perfonns in a particular end-user 
environment (i.e., how suitable is the product or service at meeting the user’s needs). 
DAU defines measures of suitability as the “measure of an item’s ability to be supported 
in its intended operational environment” (2012 (c)). Defining and implementing effective 
measures of suitability allows the systems engineer to track and refine the progress in 
designing a system to meet the user needs. Since measures of suitability relate to the 
user’s intended environment, they are typically used during validation testing. The 
system is validated to meet the user’s needs in the user’s defined environment using the 
objective quality evidence of measures of suitability. In this regard, measures of 
suitability are just as important as measures of performance in honing the systems 
engineering solution and ensuring the final product or service meets the user’s needs. 
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The process of identifying measures of suitability is similar to identifying 
measures of perfonnance but must also consider the system as a whole and the 
requirements for implementation or use of the system in stakeholder specified use cases. 
Measures of suitability describe how the features or functions of a system perform in a 
specified environment. Therefore, the process to develop a measure of suitability is 
similar to the process for measures of performance; however, the system is measured in a 
user-defined or operational environment. The process of detennining a measure of 
suitability begins with identifying those aspects of the system that meet the user’s need 
(i.e., tracing a user need through the requirement allocation to specific functions or 
features). Next, the measure must be viewed from the perspective of the environment or 
use-case in which the system will be tested to ensure the measure is applicable and 
sufficient to demonstrate the satisfaction of the requirement. Finally, iteration may be 
needed to adequately capture all the measures needed to capture the overall system 
performance in its user-defined environment. 
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III. SYSTEMS ENGINEERING INTEGRATION 


A. WHAT IS SYSTEMS INTEGRATION? 

Systems engineering is an iterative process concerned with the design and 
development of a product or service as a solution to stakeholder requirements; by 
contrast, systems integration is the combination of systems or systems of systems to 
satisfy stakeholder needs that cannot be satisfied by an individual system. “Systems 
integration is the unification of the objects and their interactions of energy, matter, 
material wealth, and information to provide system-level functionalities and 
performances” (Langford 2012, 174). Systems integration is useful to provide a system 
with function or performance that is unachievable through the use of the constitutive 
parts. 


1. Energy, Matter, Material Wealth, and Information 

The process of integration involves the interaction of the item’s constitutive parts. 
In other words, something significant about each individual item has created a need for it 
to be integrated with another to form a new system. At a fundamental level, these 
interactions take place via interaction of energy, matter, material wealth, or information. 
A brief exploration of the products of interaction will aid in understanding systems 
integration. 

Energy exists in many forms (e.g., heat, chemical, and kinetic). As such, the 
transfer of energy from one object to another is of major importance to systems 
integration. The interaction of objects due to integration can transfer energy internal to 
the system and interact with energy external to the system. As an example, the integration 
of objects and systems in an automobile engine transfer and translate energy in the form 
of chemical reactions (i.e., combustion of fuel) to kinetic energy (i.e., rotary motion of 
engine drive shaft) useful for the system to perform function “to move.” By-products of 
that interaction are non-useful chemicals and heat that are transferred into the external 
environment. 
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All objects are made of matter and therefore the integration of objects creates 
interaction of matter. Matter can be transferred through integration or matter can be 
unaltered, but play a critical role in the interactions of constitutive elements. For example, 
matter may be transferred as described in the automobile example above wherein 
gasoline is burned to generate kinetic energy and by-products. Matter may also interact 
but be unaltered, as seen in a tire’s interaction with the road - the material composition, 
shape, and other factors can affect the friction and therefore the interaction of the car 
system with the road. 

Material wealth plays a critical role in the development of systems and in turn, the 
integration of systems. Material wealth can include cash, its equivalents, or anything that 
can be converted into cash or its equivalents. Material wealth in a natural system may 
take the fonn of abundance of resources, such as water or oil (Langford 2010). 

The interaction of infonnation is critical to systems integration in the digital age. 
Many systems developed currently take in, utilize, and expel information in mass 
quantities. In fact some systems, such as a computer program, are entirely based upon the 
interaction of infonnation. The integration of the computer program with a computer and 
user interface enables the system to interact with another system (i.e., a person) and 
perform useful functions. 

2. Systems Integration, Capability and Mission 

Systems integration can be viewed as the integration of functions or capabilities 
from constitutive elements to form a new system, with new, unique capabilities or 
functions, and new boundary conditions or limitations. MITRE Corporation defines 
systems integration as “the composition of a capability by assembling elements in a way 
that allows them to work together to achieve an intended purpose” (MITRE 2013). The 
development of a capability or functionality that the individual system components 
cannot achieve singularly is an important foundation for discussion of mission 
engineering. The need for systems integration is therefore the identification of capability 
gaps and the integration of the functionality of systems to fill that capability gap. The 
ability for systems integration to develop capability from existing systems that lack that 
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capability has profound impact upon the application of systems integration for the 
purposes of mission engineering. 


B. THE PROCESS OF SYSTEMS INTEGRATION 

The process of systems integration is linear, vice the iterative approach used 
commonly in systems engineering. The major tasks of systems integration are to (1) 
identify and characterize the item (products or services) to be integrated, and (2) to define 
the specific interactions and integrations of the items that will produce the desired 
operational effectiveness to meet the needs of the stakeholders (Langford 2010). In order 
to identify and characterize items to be integrated, systems integrators must identify the 
limitations, functions, and characteristics of each item, understand the potential 
interactions between items to identify functions useful in meeting specified requirements, 
and finally, testing the functions identified to evaluate performance parameters and 
ascertain any limitations. 

The systems integration process necessitates a life cycle perspective and 
approach. A life cycle framework is needed for systems integration due to the focus on 
functions generated by the interaction and integration of objects. The functions produced 
may be beneficial, detrimental, or neutral and it is the job of the system integrator to sort 
the functions and prioritize them based upon the need, problem, or requirement identified 
by the user or other critical stakeholder. Using the example of a gasoline-powered 
automobile, the functions of to steer, to drive, to cool (for those with air conditioning) are 
all beneficial functions of the systems of systems integration. However, the exhaust and 
heat produced are detrimental functions of this systems integration. Therefore, when 
analyzing the constitutive elements to be integrated for their potential interactions, the 
system integrator must consider all life cycle implications and not focus on one item or 
function. Langford (2010, 173) proposes that an effective strategy for systems integration 
is to analyze “the totality of the system’s objects, identifying the expected (1) system- 
level functionalities, perfonnances, losses to achieve those performances, and boundary 
and boundary conditions; (2) physical entities and their mechanisms, EMMI [energy, 
matter, material wealth, and information], boundaries, and boundary conditions; and (3) 
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the expected behaviors from users of the new system as well as their behaviors due to the 
anticipation of tasks for the new system, their boundaries, and boundary conditions.” 
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IV. MISSION ENGINEERING 


A. SCOPE OF MISSION ENGINEERING 

Mission engineering is the use of systems or integration of systems to 
operationalize and execute a task. Systems integration methods may be used to compose 
subtasks and sub-functions of a mission to develop a mission capability. Likewise, 
systems engineering and integration processes and concepts are used to design the 
mission and verify and validate the mission solution. Mission engineering is postulated to 
be an application of system integration using concepts and terminology extended from 
the field of systems engineering. 

Figure 2 depicts a notional framework for executing mission engineering. The 
figure shows the flow of requirements from stakeholder needs to mission requirements, 
then the iterative processes of mission concept, mission design, and mission architecting. 
These functions of mission engineering are used to optimize a mission solution to the 
mission requirements and ultimately satisfy the stakeholder needs. 



Figure 2. Mission Engineering Process Diagram 
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Mission engineering may be viewed as a process of functions to realize 
stakeholder and user mission needs. As such, developing an understanding of mission 
engineering requires analysis from a functions perspective. Identifying the individual 
functions and sub-functions that constitute the overall process of mission engineering 
allows the mission engineer to more accurately define the steps necessary to proceed 
through a successful mission engineering iteration. Additionally, specific functions of 
mission engineering may be used to develop perfonnance, suitability, and effectiveness 
measures. For example, Figure 3 shows a functional decomposition of mission 
engineering; in the architecting phase, the function of “to analyze human interfaces” may 
be used to map specific measures of perfonnance or suitability to human systems 
integration requirements. In this manner, a functional view of mission engineering is 
important to develop successful processes and metrics for implementing mission 
engineering. 
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Figure 3. Functional Decomposition of Mission Engineering 

The focus of mission engineering is on a life cycle basis, as opposed to focusing 
on the design and development of a specific system to meet specified requirements. 
Mission engineering requires a life cycle perspective because it is more than the 
integration of an operational user with a system; the mission performance is impacted by 
aspects such as evolving stakeholders and evolving stakeholder requirements, future 
changes to constraints placed on the mission, and evolution of the mission itself due to 
upgrade or obsolescence. Figure 4 illustrates mission engineering life cycle concerns that 
must be addressed in parallel with and are integral to mission development. 
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Figure 4. Mission Engineering Life-Cycle Considerations 


B. MISSION CONCEPT 

1. Defining Mission Concept 

In order to understand a mission concept, similar concepts in industry are 
explored. In business, a mission statement is used to declare a purpose or strategic vision 
of an organization. The mission statement can be defined as a strategic posture and 
establishes the framework for a business to evaluate alternatives for how to proceed in 
potential product or service opportunities (McGinnis 1981). The mission statement 
distinguishes a particular business from others in the field, providing direction, 
objectives, and strategy (Forest 2003). In the military, a mission concept can be 
elucidated as a concept of operations. A concept of operations as defined in the United 
States Department of Defense Dictionary of Military and Associated Terms, a concept of 
operations is a clear, concise verbal or graphic statement that describes what is intended 
to be accomplished and what resources will be used (Department of Defense 2015). The 
concept of operations establishes a baseline framework for conceptualizing and analyzing 
the mission objectives and requirements. The concept may be iterated upon until the true 
need of the user or stakeholders is satisfied. A parallel can be drawn between the 
establishment of the concept of operations and the identification of system level 
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requirements. The system level requirements are decomposed into specific sub-system or 
functional element solutions with traceability back to the system level need through the 
use of allocated requirements. Similarly, a concept of operations is used to describe the 
overall mission concept and any systems used or integrated to solve the mission need. A 
mission concept as used herein is a clear, brief explanation or diagram of the mission 
objectives or operational needs, limitations, and resources to be used. 
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Figure 5. Mission Concept Context Diagram 


The mission concept, depicted in Figure 5, provides the mission engineer with a 
framework to understand the operational needs to be satisfied and the limitations or 
constraints that bound the solution space for defining a mission. Mission engineering, and 
therefore mission concepts, must consider life cycle implications and interactions. The 
operational needs, limitations, and resources available may all change over the course of 
the mission life cycle and therefore must be considered and actively planned for during 
the mission concept phase. One mechanism to incorporate life cycle considerations into 
the mission concept phase is through analysis of the feasibility of the mission concept. 

2. Analyzing Feasibility of Mission Concept on Life Cycle Basis 

A mission concept will form the basis to flow through the mission engineering 
process. As such, the mission concept must have a solid foundation based upon analysis 
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of life cycle considerations. In brief, a mission concept must be attainable, practicable, 
and effective to support the operational needs and objectives. Analysis from a life cycle 
perspective will enable the mission engineer to develop mission concepts that can meet 
the current operational needs but also be agile to support evolving operational needs, 
stakeholders, mission designs and architectures, policies, and other life cycle 
considerations. Some life-cycle considerations identified and discussed in more detail 
include management of stakeholders, requirements, configuration, communication, and 
logistics; risk assessment and management; human systems integration; energy and 
sustainability; information assurance and cybersecurity; safety; security; policy, media, 
and legal support services; training and documentation. 

C. MISSION DESIGN 

1. Developing Mission Design 

Following the mission concept phase, the mission engineering process, shown in 
Figure 2, proceeds into the mission design phase. Mission design, illustrated in Figure 6, 
is the decomposition of the mission objectives and necessary functions, in the form of 
mission requirements, using the guidance of the mission concept as a framework, to 
develop sub-tasks and sub-functions that must be satisfied to perform the mission. In 
this manner, mission design is not dissimilar to the systems engineering processes of top- 
down requirements derivation and systems design and development to satisfy specific 
functions. Additionally, systems integration processes may be leveraged during mission 
design to satisfy functions and capabilities that cannot be accomplished at an elemental 
level (i.e., with an individual system solution). 
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Figure 6. Mission Design Diagram 


The mission design process incorporates methods to assess the capabilities and 
functions performed by the mission design, but also evaluates the interaction of the 
mission design with life cycle factors. Verification and validation processes leveraged 
from systems engineering are proposed to maximize the effectiveness of mission design. 
Clear, concise definition of mission sub-tasks and sub-functions will enable more 
successful verification and validation of the ultimate mission design solution. Measures 
of performance and suitability provide the data to track the progress of the mission design 
in satisfying the mission sub-functions as well as the overall required capabilities. As 
used in systems engineering, measures of performance are used to provide evidence and 
justification to a mission design verification process; the mission design verification 
process is used to ensure mission requirements are satisfied. Measures of suitability are 
used in a mission design validation process to demonstrate a proposed capability or 
proposed mission solution in a prescribed environment; for example, a mission function 
or capability that is required to be executable in multiple environments (e.g., humid, 
jungle climate or cold, wintery climate) may be validated individually to demonstrate 
suitability in each environment. 

2. Evaluating Mission Design for Effectiveness on Life Cycle Basis 

Functional analysis and decomposition of mission design is used to identify and 

quantify the capabilities and functions needed to meet the mission requirements. The 

functional analysis of “to design a mission” highlights the influences on mission design 
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allowing parameters for specific sub-functions to be determined for measuring mission 
design effectiveness. The function decomposition of mission design depicted in Figure 7 
shows the processes and influences upon mission design. The identification and analysis 
of requirements and constraints are a major consideration when designing a mission (just 
as they are when engineering a system). Additionally, management of life-cycle 
considerations is important for the mission engineer to establish measures of 
effectiveness that will accurately characterize the mission solution and how well it 
satisfies the needs of the stakeholders. Figure 7 shows a notional functional diagram to 
describe the process of designing a mission. The figure also shows an example of how a 
measure of effectiveness for the system may be derived through the functional 
breakdown for life-cycle issues that influence the mission design. 
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Figure 7. Functional Diagram of Mission Design 


The effectiveness of a mission design in satisfying the stakeholder needs must 
also consider life cycle factors. Life cycle factors may be described as external influences 
upon a system (the mission design). Mission design meets the stakeholder requirements 
for a desired capability using a systems engineering framework, but the mission design 
also employs systems integration methods to consider capabilities derived from the 
interrelation of systems as well as life cycle influences. Life cycle factors may drive an 
agile mission design solution that can adapt to changing stakeholders, needs and 
requirements or may drive the design solution to very specific solutions, such as 
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restrictions based upon requirement for a human interface. For successful mission design, 
in addition to the decomposition of mission capabilities into sub-tasks, life cycle 
considerations and their impact, interactions and boundary conditions with each 
capability, sub-task, and function are analyzed. The discretization of the elements of 
mission design and their interactions with life-cycle considerations enables the mission 
engineer to use measures of effectiveness with life cycle focus detennined for each sub 
function and the overall mission design and iterate or trade-off mission trade-space as 
needed. 

D. MISSION ARCHITECTURE 

1. Selecting Mission Architecture 

In general, the architecture of an object is its structure or fonn. Langford (2012, 
353) describes architecture as “conceptual or logical structures of objects and processes.” 
In that vein, mission architecture is the representation, structure or implementation of the 
mission design. While mission design is centered upon the satisfaction of required 
capabilities and functions, mission architecture focuses on how the mission design is 
implemented, or the structure of the mission. As such, the dominant activity in selecting a 
mission architecture it the tradeoff between the effectiveness of the mission design, cost, 
and risk. 

2. Analyzing Mission Architecture, Tradeoff Cost, Effectiveness, and 
Risk on a Life Cycle Basis 

In the mission architecture phase of mission engineering, tradeoffs between 
mission effectiveness, cost, and risk are conducted to detennine the optimal mission 
solution. With unbounded resources of schedule and cost, mission design and architecture 
could be optimized to maximize effectiveness. However, we live in a world bounded by 
cost and schedule considerations and therefore the mission engineer must balance the 
mission architecture solution with overall mission effectiveness to deliver an acceptable 
mission solution. Life-cycle considerations influence the trade space because they 
interact with and potentially modify the boundary conditions of the architecture and 
mission design, thereby influencing the effectiveness, cost, and risk assumed by the 
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mission solution. The mission architecture delineates how the mission design is 
structured and conveyed to the end-user and other key stakeholders. 

The boundary of an object or function is where it interacts with other objects, 
functions, or the surrounding environment. Langford (2012, 354) describes boundary 
conditions as the “mediation of capabilities that enact across boundaries.” Boundary 
conditions limit the interaction of objects or functions or prescribe how the interaction of 
objects or functions takes place. Life-cycle considerations, such as stakeholder or 
requirements management, modify the boundary conditions of the mission trade space. 
For example, modification, addition, or deletion of a requirement may greatly influence 
the mission design and architecture. Likewise, other life-cycle considerations, such as 
risk management, are dependent upon the mission design and architecture and the 
boundary conditions that exist due to both mission requirements and the interaction of the 
mission with life-cycle influences. 

Risk is an important consideration during mission design and architecture trade 
studies. Risk management is a formal process to identify, track, mitigate, and manage 
potentially negative impacts to a program (Department of Defense 2013). Risk 
assessment and management is a life-cycle consideration because it affects the mission 
engineering process throughout. The mission architecting phase is the final stage before a 
mission solution is achieved and therefore is the culmination of risk identified throughout 
the mission engineering process. The iteration of the mission architecture will tradeoff 
risk identified and generated by the architecture, with cost and effectiveness of the 
solution. 

E. LIFE CYCLE CONSIDERATIONS 

1. Stakeholder Management 

In systems engineering, stakeholder analysis is a process for identifying and 
classifying stakeholders, understanding stakeholder relationships, determining key 
stakeholders, and defining stakeholder requirements (Langford 2012). Stakeholder 
management goes a step further by actively engaging and interacting with stakeholders in 
order to more effectively and efficiently perform continuous stakeholder analysis. 
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Stakeholder management is also a business management term relating to the 
relationships businesses form with their stakeholders. The principles of stakeholder 
management, shown in Table 1, are also applicable to mission engineering. Of specific 
importance to mission engineering is the focus on communication and cooperation with 
stakeholders. Stakeholders cannot be controlled, but should be managed with openness 
and active communication to promote positive relationships, teamwork, and more 
efficient understanding of stakeholder requirements and needs. Positive stakeholder 
relationships can promote trust and collaboration, which can generate success and 
understanding through teamwork. Negative stakeholder relationships can foster distrust 
promoting formalized discussions resulting in time delays and cost increases (Philosophy 
Documentation Center 2002). 
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Table 1. Principles of Stakeholder Management (after Philosophy 

Documentation Center 2002) 


Principle 1 

Managers should acknowledge and actively monitor the concerns of all 
legitimate stakeholders, ad should take their interests appropriately into 
account in decision-making and operations. 

Principle 2 

Managers should listen to and openly communicate with stakeholders about 
their respective concerns and contributions, and about the risks that they 
assume because of their involvement with the corporation. 

Principle 3 

Managers should adopt processes and modes of behavior that are sensitive 
to the concerns and capabilities of each stakeholder constituency. 

Principle 4 

Managers should recognize the interdependence of efforts and rewards 
among stakeholders, and should attempt to achieve a fair distribution of the 
benefits and burdens of corporate activity among them, taking into account 
their respective risks and vulnerabilities. 

Principle 5 

Managers should work cooperatively with other entities, both public and 
private, to insure that risks and harms arising from corporate activities are 
minimized and, where they cannot be avoided, appropriately compensated. 

Principle 6 

Managers should avoid altogether activities that might jeopardize 
inalienable human right (e.g., the right to life) or give rise to risks, which, if 
clearly understood, would be patently unacceptable to relevant stakeholders. 

Principle 7 

Managers should acknowledge the potential conflicts between (a) their own 
role as corporate stakeholders, and (b) their legal and moral responsibilities 
for the interests of stakeholders, and should address such conflicts thorough 
open communication, appropriate reporting and incentive systems, and 
where necessary, third party review. 


As a system, or mission, progresses through its life cycle, relationships with 
stakeholders may change, or the relative influence of stakeholders may change. For 
example, in the development stages of a product, stakeholders that represent 

manufacturing abilities may initially be considered higher priority than stakeholders that 
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represent how the product is maintained. As the product progresses through its life cycle, 
the relative importance of those stakeholders may shift. Additionally, the interaction or 
relationships between stakeholders may influence stakeholder’s perspectives. When 
viewing a system or mission from the lens of its entire life cycle, these shifts in 
stakeholder priority or the modification of or interrelations between stakeholders must be 
considered and addressed. Therefore, the principles for effective stakeholder management 
from Table 1 are recommended for use within the mission-engineering construct. Open 
communication, cooperation, and avoiding activities and issues that alienate stakeholders 
are basic principles that will enable the mission engineer to more effectively identify 
needs and requirements for the mission functions and capability, as well as work 
collaboratively with stakeholders in identifying mission design and architecture solutions. 

2. Requirements Management 

Requirements management refers to all activities related to requirements 
following the initial development of requirements (Hood 2008). Requirements 
management is important because requirements may be modified, added, or deleted 
during the course of the life cycle due to changes in stakeholder needs or changes in the 
stakeholders themselves. Requirements are integral to successful systems engineering and 
systems integration to ensure, because the processes to design, develop, integrate, test, 
verify, and validate systems relate back to the requirements. Therefore, management of 
requirements throughout the life cycle is critical to successful systems engineering, 
systems integration, and likewise mission engineering. In mission engineering, 
requirement may take the form of a function, capability, objective, or problem to 
overcome through the execution of a function or capability. Therefore, requirements 
management includes the activities related to the tracking of mission capabilities 
throughout the mission concept, design, and architecting phases. Requirements 
management involves communication with stakeholders to understand how mission 
capabilities are evolving and internal communication and coordination to ensure the 
capabilities are properly implemented in the mission design and architecture. A 
recommendation for successful mission engineering is to plan for evolving requirements 

and capabilities through open architectures and universal interfaces. 
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3. Configuration Management 

The United States DOD’s Defense Acquisition Guidebook defines configuration 
management as “the principle methodology for establishing and maintaining consistency 
of a system’s functional, perfonnance, and physical attributes with its requirements, 
design, and operational information throughout the systems life cycle” (Department of 
Defense 2013, 311). Configuration management aids the mission engineer in tracking the 
evolution of requirements, the mission concept, mission design, and mission architecture 
throughout the life cycle. As such, configuration management can aid the mission 
engineering process by ensuring continuity in the rationale behind decisions and trade 
space decisions. A well-developed configuration management system can also enable 
trade space decisions by tracking the relative performance, suitability, and effectiveness 
of mission solutions. 

4. Risk Assessment and Management 

Risk is the potential for something to go wrong and therefore planning for risk 
and actively mitigating risk is important to a successful program, system development, or 
mission. Risk management is the iterative process to plan, identify, assess, analyze, and 
track risks (Blanchard and Fabrycky, 2011). The DAG describes risk management as the 
oversight program for identification, analysis, mitigation planning and implementation, 
and tracking of risk throughout the life cycle. Risk analysis and management mitigates 
uncertainties and therefore impacts cost, schedule, and perfonnance goals throughout the 
life cycle (Department of Defense 2013). 

Risk analysis and management are important considerations during the mission¬ 
engineering life cycle. Since mission engineering is analogous to systems integration, an 
active and robust risk program needs to be integral and pervasive to the mission 
engineering processes in order to effect early and often identification of risks, planning 
and implementation of mitigation strategies, and tracking of risks. Throughout the 
mission engineering process, trade space is used to balance the programmatic influences 
of cost and schedule with satisfying requirements in a manner that produces a solution 
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that is effective to satisfy the needs of the stakeholder. Risk is therefore pervasive in the 
mission engineering process as design and architecture decisions are made. 

5. Communication Management 

Communication management includes the oversight of all processes by which 
information is generated, collected, stored, retrieved, and disposed of on a project. 
Communication in mission engineering is important for interfacing with members within 
the organization (e.g., team members or management) and external to the organization 
(e.g., stakeholders or sponsors). The management of communication both internal and 
external to the mission engineering organization is important for stakeholder interaction, 
correct interpretation and implementation of requirements, and managing the flow of 
information pertinent to the organization. 

6. Human Systems Integration 

Many definitions and implementations of human systems integration exist, and so 
several are explored to provide context to a discussion of human systems integration. 
Next the implications of human systems integration in the field of mission engineering 
are discussed. 

Blanchard and Fabrycky (2011) state that for a system to be operationally 
effective, human factors must be considered early and throughout the system life cycle. 
Additionally, and of note, is the identification that human factors are not solely due to the 
direct interaction of humans with the final system; humans may be involved in training, 
maintenance, planning, manufacture, and many aspects of the systems engineering life 
cycle. As such, human factors planning, or human systems integration is truly a 
consideration across the life cycle. 

The U.S. Air Force Human Systems Integration Handbook (Department of 
Defense 2009, 8) describes human systems integration as “a robust process to design and 
develop systems that effectively and affordably integrate human capabilities and 
limitations.” A key emphasis of the Air Force Human Systems Integration Handbook is 
that humans and their limitations are integral components of a developed system and 
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therefore a human’s capacities and limitations must be considered throughout the design 
and development of a system (Department of Defense 2009). 

The DAG promotes a total systems approach to human systems integration, 
meaning that human aspects of system design such as manpower, training, environment, 
safety, occupational health, and personnel survivability considerations are incorporated 
into the design and acquisition process. It is argued that successful human systems 
integration can only be achieved through comprehensive integration of human systems 
requirements in order to identify and close technology and performance gaps in the 
system (Department of Defense 2013). This definition of human systems integration is 
important because it highlights that human systems integration is not a process to derive 
requirements based upon human limitations to be satisfied during the design phase; 
rather, this definition focuses on the need to consider human-system interactions 
throughout the life cycle of a product. 

Human systems integration is a consideration across the mission-engineering life 
cycle. Human interaction and integration with the mission engineering process may be in 
many forms, such as training, planning or execution of the mission. Therefore, the role 
humans play in the system to affect or limit mission capability and functionality is an 
important metric to judge the effectiveness of a mission. 

7. Sustainability 

The DAG describes sustainability as the trait of using fewer resources over the life 
cycle and having fewer impacts on human health and the environment (Department of 
Defense 2013). Sustainability from a mission engineering perspective helps to reduce 
cost, increase mission readiness, and improve mission effectiveness. Reducing the life- 
cycle resources required or the human and environmental impacts helps to reduce the 
life-cycle cost due to a general reduction in resources required to support the system, or a 
reduction in necessary resources allocated to a solution to compensate for human or 
environmental impacts. Mission readiness and effectiveness may also be improved if 
fewer resources are required as there are fewer points of failure, which could impede 
successful execution of the mission. 
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8. Information Assurance and Cybersecurity 

The Department of Defense Dictionary of Military and Associated Terms defines 
information assurance as “actions that protect and defend information systems by 
ensuring availability, integrity, authentication, confidentiality, and nonrepudiation” 
(Department of Defense 2015, 118). Advances in computer networks, information 
technology, and the growth of the Internet have contributed to a high degree of 
information sharing, often at a global level (Tipper 2008). As such, infonnation is 
pervasive in society including in systems engineering, systems integration, and mission 
engineering. Infonnation is used for interactions with stakeholders, the communication 
within and external to the organization, and the data or documents used in the design, 
development, implementation, training and other aspects of the life cycle. 

Infonnation assurance relates to other life cycle considerations, such as security, 
information technology management and network services management. Information 
assurance provides the policies and processes for an organization to secure their 
information technology and networks, to provide assurance that when the infonnation is 
needed it is available and can be trusted. Everything from personnel records to design 
data to training materials to contracts require some degree of and consideration for 
information assurance. As an example, the DOD has many policies and procedures for 
information assurance: DOD Instruction 8500.2 describes information assurance 
implementation practices (Department of Defense 2003); the DAG Chapter 7, Section 5 is 
devoted to information assurance, describing applicable policies, processes and strategies 
for information assurance (Department of Defense 2013). In 2015, DOD Instruction 
8500.01 replaced the term “infonnation assurance” with “cybersecurity” (Department of 
Defense 2014). Cybersecurity is a critical life cycle consideration for mission engineering 
due to the pervasive use of information in modem systems and organizations. Methods to 
achieve cybersecurity may create derived requirements on the mission design and 
mission architecture and create additional trade space for satisfying the mission concept 
within allowable policies, cost, schedule, and other factors. The mission engineer, 
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therefore, needs to consider all applicable policies early in the mission-engineering life 
cycle, generate a cybersecurity plan, and implement a cybersecurity process through the 
mission life cycle. 

9. Safety 

Safety can be a driving life cycle consideration, especially when there is the 
potential for human injury or loss of life. Safety concerns may be addressed within the 
mission design space due to human systems integration concerns. Identification of safety 
concerns may also relate to the successful or unsuccessful preparation for, execution of, 
or recovery from the mission. For example, testing mission functions and capabilities 
may necessitate specific safety procedures be followed to be in compliance with local 
ordinances or laws. 

10. Security 

Security encompasses the aspects of the system that prevent the intentional harm 
or destruction of the system, personnel, the surrounding environment, or society 
(Blanchard 2011). Security can come in many forms, from physical security such as 
locks, alarms, and security guards, to non-physical forms of security, such as cyber 
security. Cybersecurity is related to infonnation assurance and is discussed in this thesis 
in that context. Physical security measures may depend on the stakeholders, the subject of 
a system or mission, or the purpose to a system or mission. Some organizations impose 
physical security measures to secure trade secrets and proprietary information, while 
others, especially the DOD and other government organizations, may use physical 
security as one tenet in protecting classified information whose release could harm the 
interests of the U.S. Government. Security policies and procedures need to be 
documented early in the mission-engineering life cycle and addressed on a continual 
basis as needed due to other life cycle considerations such as evolving stakeholder 
involvement, requirements modifications, development of new technologies, or changes 
to the mission parameters. 
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11. Policy, Media, and Legal Support Services 

Policy, media, and legal support services are important considerations throughout 
the life cycle of mission engineering. However, the scope of these areas may vary widely 
depending on the level of human interface and involvement, the capabilities and purposes 
of the mission, or the perceptions of society or the environment in which the mission is 
executed. In the government arena, policy and laws will act as boundary conditions to 
shape the mission concept, design, and architecture. Additionally, government spending 
and actions are often public knowledge and therefore the media may be a factor in public 
perception of a government developed or executed mission. Finally, legal support 
services may be needed throughout the mission engineering process in areas such as 
contract development and execution, and compliance with applicable policies, laws and 
statutes. 

12. Training and Documentation 

Training and documentation are an important consideration throughout the life 
cycle of mission engineering. Documentation during the development of a mission is 
important for managing the mission engineering processes and all of the internal and 
external interactions. Training must also be considered throughout the mission 
engineering life cycle because in order for humans to interact with the system or systems 
and perfonn an effective mission the capabilities, functionalities, and limitations must be 
conveyed. As such, early attention to training may influence the development of an easier 
to perform mission. Likewise, late attention to training and how humans may interface 
with the mission systems may lead to ineffectual or impossible missions to perform. 

13. Logistics Management 

Logistics, or the flow of resources, is inherently critical to the mission engineering 

process. Properly managed logistics can enable mission success, whereas poor logistics 

management will doom a mission to failure. Every system, system of systems, and 

therefore mission, relies on the supply and flow of resources. These may include 

resources to initially create a system or integrate a system, or may include resources 

needed to sustain a capability or function. For example, fuel for vehicles integral to the 
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mission performance is a critical resource to manage to ensure continued mission 
execution. Logistics management early in the mission engineering process can enable a 
more versatile and agile mission solution. 


F. DEFINING MISSION ENGINEERING 

Using systems integration as a framework and extrapolating systems engineering 
concepts, the following definition of mission engineering is proposed: 

Mission Engineering is a life cycle-based, integrative approach to develop and 
implement capabilities and functions from stakeholder needs into executable missions 
while balancing performance, risk, cost and schedule. 

This definition offers the emerging field of mission engineering a baseline 
construct to continue to define mission engineering processes and vernacular. Systems 
engineering processes of stakeholder analysis, requirements analysis, and life cycle 
consideration analysis are extrapolated to a management paradigm, whereby the mission 
engineer is chartered with actively managing those life cycle concerns in order to produce 
a successful mission. Specific systems engineering terms and processes such as 
verification, validation, and their associated metrics of effectiveness, performance, and 
suitability are recommended to aid in more efficient and effective mission engineering. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

Execution of mission engineering requires fonnalized definitions and processes to 
ensure consistency, repeatability, and effectiveness. Systems engineering and integration 
have well-developed tenninology and clear, executable processes that are applicable and 
are recommended to be used in the execution of mission engineering. Specifically from 
systems engineering, stakeholder and requirement analysis, verification and validation 
processes, and associated measures of effectiveness, perfonnance, and suitability are 
foundational elements that can be tailored for unique missions and mission-focused 
processes to ensure mission requirements are clearly defined, allocated, and ultimately 
met by the mission solution. Additionally, systems integration should be used as the 
framework for understanding mission engineering as mission engineering involves the 
integration of systems or systems of systems to execute stakeholder defines capabilities 
and functions. Systems integration provides a means to develop capabilities, functions, 
and solutions to problems beyond those of individual systems. In this manner, systems 
integration is a good foundation for mission engineering. Figure 2 provides a notional 
process depiction for executing mission engineering. The major processes within mission 
engineering are the mission requirements derivation from stakeholder needs, mission 
conceptualization, mission design, and mission architecting. Within each of these phases, 
and throughout the mission engineering process, life cycle considerations must be 
accounted for and reacted to, as needed. Each phase of mission engineering by itself is 
iterative to ensure tradeoffs and decisions are well developed and executed; however, the 
ultimate flow of mission engineering is linear, proceeding from mission concept to 
mission design to mission architecture. Iterations of design architecture are based upon 
measures of effectiveness, performance, and suitability depending on the specificity of 
the capability or function in question and the stage in the mission engineering process. 
Perfonnance measures may be used early and often to verily specific aspects of the 
mission design, whereas measures of suitability and effectiveness are more often used 
later in the mission engineering process when closer to a final solution. Mission 
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Engineering is a life cycle-based, integrative approach to develop and implement 
capabilities and functions from stakeholder needs into executable missions while 
balancing performance, risk, cost and schedule. 


B. RECOMMENDATIONS 

A recommendation for future study is to explore further the emerging field of 
mission engineering. While this thesis proposes a construct of mission engineering 
utilizing the framework of systems integration and the tools and processes of systems 
engineering, additional specificity for mission engineering unique processes may be 
beneficial. Additional detail in mission engineering processes and terminologies may 
allow for greater application of mission engineering and may result in an entirely separate 
field of study from systems engineering. 
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